Given this slows down development both for us and external contributors
as for most changes one would need to run `go mod vendor` in /test to
bring in the latest local hcsshim changes, I think it's time we removed
this.

Pros:
1. Easier for automated tooling like dependabot, and more recently a
Microsoft security bot, to make PRs that can just be checked in.
All of these automated PRs tend to fail as the bot doesn't know it would
need to run go mod vendor in /test as well for our repo. The approach today
to check these in is typically someone manually checks out the branch
dependabot (or whatever other bot) made, vendor to test, and then push a
new commit to those automated PRs and then we can check them in.

2. Speeds up development flow as we don't need to go mod vendor in test
before pushing almost every change.

3. Speeds up external contributions as well as there's no extra step to
follow to make a change to most things in /internal anymore. We state that
this needs to be done in our README, but it's probably a testament to how
odd our setup is that it's missed here and there.

Cons:
1. We lose the main selling point of vendoring for our test dependencies
which is that if one of our dependencies is no longer accessible
(deleted, renamed, whatever else) we don't have a local copy included
in our repo. This will increase our dependence on the Go modules proxy
server which seems like a fair tradeoff, and I think we're fine with this for
test dependencies at least.

I've removed the references to this extra step in the README as well as
got rid of the CI step verifying that the vendor dir was up to date. I
don't think we needed the mod=vendor env var either, as since go 1.14 if
there's a top level vendor folder I believe the flag is transparently set
for commands that accept it.

Signed-off-by: Daniel Canter <dcanter@microsoft.com>

Given this slows down development both for us and external contributors
as for most changes one would need to run `go mod vendor` in /test to
bring in the latest local hcsshim changes, I think it's time we removed
this.

Pros:
1. Easier for automated tooling like dependabot, and more recently a
Microsoft security bot, to make PRs that can just be checked in.
All of these automated PRs tend to fail as the bot doesn't know it would
need to run go mod vendor in /test as well for our repo. The approach today
to check these in is typically someone manually checks out the branch
dependabot (or whatever other bot) made, vendor to test, and then push a
new commit to those automated PRs and then we can check them in.

2. Speeds up development flow as we don't need to go mod vendor in test
before pushing almost every change.

3. Speeds up external contributions as well as there's no extra step to
follow to make a change to most things in /internal anymore. We state that
this needs to be done in our README, but it's probably a testament to how
odd our setup is that it's missed here and there.

Cons:
1. We lose the main selling point of vendoring for our test dependencies
which is that if one of our dependencies is no longer accessible
(deleted, renamed, whatever else) we don't have a local copy included
in our repo. This will increase our dependence on the Go modules proxy
server which seems like a fair tradeoff, and I think we're fine with this for
test dependencies at least.

I've removed the references to this extra step in the README as well as
got rid of the CI step verifying that the vendor dir was up to date. I
don't think we needed the mod=vendor env var either, as since go 1.14 if
there's a top level vendor folder I believe the flag is transparently set
for commands that accept it.

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
(cherry picked from commit 4e60239)
Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>

Given this slows down development both for us and external contributors
as for most changes one would need to run `go mod vendor` in /test to
bring in the latest local hcsshim changes, I think it's time we removed
this.

Pros:
1. Easier for automated tooling like dependabot, and more recently a
Microsoft security bot, to make PRs that can just be checked in.
All of these automated PRs tend to fail as the bot doesn't know it would
need to run go mod vendor in /test as well for our repo. The approach today
to check these in is typically someone manually checks out the branch
dependabot (or whatever other bot) made, vendor to test, and then push a
new commit to those automated PRs and then we can check them in.

2. Speeds up development flow as we don't need to go mod vendor in test
before pushing almost every change.

3. Speeds up external contributions as well as there's no extra step to
follow to make a change to most things in /internal anymore. We state that
this needs to be done in our README, but it's probably a testament to how
odd our setup is that it's missed here and there.

Cons:
1. We lose the main selling point of vendoring for our test dependencies
which is that if one of our dependencies is no longer accessible
(deleted, renamed, whatever else) we don't have a local copy included
in our repo. This will increase our dependence on the Go modules proxy
server which seems like a fair tradeoff, and I think we're fine with this for
test dependencies at least.

I've removed the references to this extra step in the README as well as
got rid of the CI step verifying that the vendor dir was up to date. I
don't think we needed the mod=vendor env var either, as since go 1.14 if
there's a top level vendor folder I believe the flag is transparently set
for commands that accept it.


(cherry picked from commit 4e60239)

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>